home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 26 / Cream of the Crop 26.iso / program / nasm095.zip / RDOFF / RDOFF.TXT < prev    next >
Text File  |  1997-07-27  |  4KB  |  115 lines
  1. The RDOFF version 1.1 Object File Format
  2. ========================================
  3.  
  4. I seem to keep writing this document... I don't know what keeps
  5. happening to it. Anyway, this one will hopefully stay around for a
  6. while.
  7.  
  8. RDOFF is a relocatable object file format whose design goals were
  9. mainly to keep it simple, so that an RDOFF object can be loaded and
  10. executed by a very small piece of code (primarily so that it can be
  11. used by the microkernel of an operating system to store system
  12. modules, which can then go on to load and execute more complex object
  13. files, eg ELF, if so desired), yet still be able to be cope with
  14. everything required by the operating system; linkage of multiple
  15. modules together (possibly with automatic loading of new libraries
  16. that are referred to by the object) at load time, allowing static or
  17. dynamic linking as required by the application.
  18.  
  19. The overall format of the file is summarised in this table:
  20.  
  21. Length (bytes)        Description
  22.       6        Contains the string 'RDOFF1' (little-endian targets),
  23.         or 'RDOFF' followed by the single byte 0x01
  24.         (big-endian targets).
  25.       4        Length of the header section
  26.       ?        Header section (see above for length)
  27.       4        Length of code section (.text)
  28.       ?        Code section
  29.       4        Length of data section (.data)
  30.       ?        Data section
  31.  
  32. Segments are referred to as numbers. Imported labels are implicitly
  33. at offset zero from a segment; each is assigned a segment number when
  34. it is imported. Segments in the object file itself are numbered:
  35.     0 - text segemnt
  36.     1 - data segment
  37.     2 - bss segment
  38.  
  39. The header consists of a sequence of records, each of which is
  40. preceded by a byte to represent its type.
  41.  
  42. These records are one of the following types:
  43.  
  44. 1: Relocation Record
  45. --------------------
  46.  
  47.     This record points to an address that will need either
  48.     relocation or linkage to an external segment when the object
  49.     is loaded or linked.
  50.  
  51.     Length        Description
  52.       1    Type identifier (must be 1)
  53.       1    Segment number (0 or 1) plus 64 if the reference is
  54.         relative (and thus does not require relocation with
  55.         the base of the code, only by the difference between
  56.         the start of this segment, and the segment referred to
  57.         (see below)
  58.       4    Offset from start of segment of item requiring reloc.
  59.       1    Length of item (1, 2, or 4 bytes...)
  60.       2    Segment number to which reference is made.
  61.  
  62. 2: Import Symbol Record
  63. -----------------------
  64.  
  65.     This record defines a segment to start at the location of a
  66.     named symbol; this symbol may need to be fetched from an
  67.     external library.
  68.  
  69.     Length        Description
  70.       1    Type identifier (must be 2)
  71.       2    Segment number to allocate
  72.       ?    String containing label (null terminated, max length =
  73.         32 chars)
  74.  
  75. 3: Export Symbol Record
  76. -----------------------
  77.  
  78.     This record defines a symbol, to which external modules can
  79.     link using the above record type.
  80.  
  81.     Length        Description
  82.       1    Type identifier (must be 3)
  83.       1    Segment containing symbol (0,1 or 2)
  84.       4    Offset of symbol within segment
  85.       ?    String containing label (null terminated, max length =
  86.         32 chars)
  87.  
  88. 4: Import Library Record
  89. ------------------------
  90.  
  91.     This record tells the loader that an extra library should be
  92.     loaded and linked to the module at either load- or run-time
  93.     (load time is easier, run-time is good, though...)
  94.  
  95.     Length        Description
  96.       1    Type identifier (must be 4)
  97.       ?    Name of library (null terminated string, max len = 128)
  98.  
  99. 5: Reserve BSS Bytes
  100. --------------------
  101.  
  102.     This record tells the loader how much memory to reserve after
  103.     the executable code loaded from the object file for the BSS
  104.     segment (referred to as segment number 2).
  105.     A loader can safely assume that there will only be one of
  106.     these records per module, but the linker probably cannot...
  107.     NASM will only output one, but other utilities may be written
  108.     that do, and future versions of NASM may output more than one.
  109.  
  110.     Length        Description
  111.       1    Type identifier (must be 5)
  112.       4    Number of bytes to reserve
  113.  
  114.  
  115.